Serving network entity relocation

ABSTRACT

A method ( 400 ) for relocating a serving network entity is presented. Before the relocation certain packet data information is transmitted between a terminal and a first network entity ( 901 ) at least via a second network entity ( 902 ) and via a third network entity ( 903 ). The first network entity ( 901 ) is connected to the second network entity ( 902 ) with a first path ( 911 ) and to a third network entity ( 903 ) with a second path ( 902 ), and the second network entity, which is before the relocation acting as the serving network entity, is connected to the third network entity, which is its peer network entity and after relocation acting as the serving network entity, with a third path ( 903 ). The first, second and third paths are separate paths. After the relocation said information is transmitted via the third network entity. The method is characterized in that the need for relocation of the serving network entity is communicated ( 403, 601 ) to the third network entity by the peer second network entity using the third path.

[0001] The invention relates in general to cellular networks thatsupport transmission of packet data. In particular the invention relatesto performing a serving network entity relocation from a certain networkentity to a peer network entity.

[0002] Traditionally cellular systems, for example the Global System forMobile telecommunications (GSM), have been used to transmit speech andthey have implemented circuit switching. In circuit switching a certainamount of transmission resources is reserved in all the networks throughwhich the connection goes. For new data applications there is usuallyneed to transmit bursts of data every now and then. For this kind ofdata transmission circuit switching is not an efficient way to transmitdata.

[0003] In the Universal Mobile Telecommunication System (UMTS) bothpacket switching and circuit switching are supported. When a mobilestation, or a user equipment as the portable terminal communicating withthe UMTS system is usually called, is changing its position, the networkelements through which its packet switched data or circuit switchedconnections change. The UMTS system keeps track on the position of theuser equipment, and the circuit switched connections are re-routed in asimilar manner as in GSM, for example, and the packet switched data isre-routed similarly as in General Packet Radio Service (GPRS).

[0004] In the core UMTS network the packet switched data and the circuitswitched connections may be transmitted using separate networks. Thecore network of UMTS transmitting the packet data may be, for example,and Internet Protocol (IP) based network. The user equipment is attachedto the core UMTS network through a radio access network (RAN). Both thepacket switched data and the circuit switched connections flow throughthe same radio access network.

[0005]FIG. 1 presents a schematic diagram of a UMTS radio access network(RAN) 110 and UMTS core network 120. In FIG. 1 the UMTS core network120, as one example of realizing the UMTS core network, comprises twoseparate core networks: the circuit switched core network (CS-CN) 130and the packet switched core network (PS-CN) 140. The CS-CN 130 is verysimilar to GSM core network and comprises mobile services switchingcenters (MSCs), through which circuit-switched connections run. FIG. 1presents MSCs 131 a and 131 b. In the common part of the UMTS corenetwork 120 there is a data base, Home Location Register (HLR) 121,where information about the mobile stations is stored. The PS-CNcomprises GPRS Supporting Nodes (GSNs) which act as routers withadditional mobility functions. The data packets run through the GSNs.The GSNs facing the UMTS RAN 110 are Serving GPRS Supporting Nodes(SGSN). The SGSN is at the same hierarchical level as the MSC; it, forexample, keeps track of the individual MSs' location and performssecurity functions and access control. The GSNs facing other packet datanetworks are Gateway GPRS Supporting Nodes (GGSN). FIG. 1 presents twoSGSNs 141 a, 141 b, and one GGSN 142 which faces a packet data network150. The packet data networks to which UMTS core network is connectedthrough a GGSN may be, for example, the Internet or a X.25 data network.

[0006]FIG. 1 shows base stations (BTS) 111 a, 111 b, 111 c, 111 d of theUMTS RAN 110. A mobile station communicates with these base stationsover the radio interface. One or more base stations are connected to aradio network controller (RNC). The RNCs face the UMTS core network andthey are connected to MSCs and/or SGSNs. It is possible to connect toeach MSC or SGSN many RNCs. The RNC is responsible, for example, forallocation of radio resources and for handling handovers, where a mobilestation changes cell. FIG. 1 shows two RNCs 112 a, 112 c.

[0007] Here term cell is used to refer to the area covered either by abase station or, if a base station comprises many transmitters, by oneor more transmitters. A group of cells, whose base stations areconnected to a part of, one or more RNC form a Location Area (LA), whichterm is used in connection with circuit switched connections, or aRouting Area (RA), which term is used in connection with packet switcheddata. FIG. 1 present two Location/Routing areas 113 a and 113 c.

[0008] A mobile station performs a UMTS PS attach procedure in order toobtain packet data services, in other words to inform to the UMTS systemthat it can send and/or received packet data. The UMTS PS attachestablishes a logical link between the MS and the SGSN, and makes the MSavailable for, for example, paging via SGSN and notification of incomingpacket data. When it actually has packet data to transmit, it performs aPacket Data Protocol.(PDP) context activation.

[0009] Consider, as an example, a data packet flow between MS 101 and aterminal 151 in FIG. 1. The route of the data is MS 101—BS2 111 b—RNC1112 a—SGSN1 141 a—GGSN 142—packet data network 150—terminal 151. The PDPcontext activation has established a tunnel between the SGSN1 141 a andthe GGSN 142. Data between SGSN and GGSN is transmitted using a GPRStunneling protocol (GTP), which typically runs on IP. Signaling takesplace using the same protocol. Between the SGSN and the RNC data istransmitted using the same GTP protocol and there is also a tunnel. TheTunnel Endpoint Identifier (TEID) indicates the data packet belonging toa certain data packet flow related to a certain MS. Each packettransmitted towards a SGSN, GGSN, or RNC carries a SGSN, GGSN or RNCTEID, correspondingly. In the RAN, the data packets are transmittedbetween the RNC and the MS typically based on the International MobileSubscriber Identifier (IMSI) of the mobile station or on a Radio NetworkTemporary Identity (RNTI) and according to the negotiated QoS (Qualityof Service) parameters.

[0010] A mobile station may be either in a PMM (Packet MobilityManagement) connected or PMM idle state. In a PMM connected state themobile station is known by an RNC and it has a RRC connection. The RNCtracks the location of the mobile station, when the mobile station is inthe PMM connected state. When the mobile station is in a PMM idle state,its location is tracked by a SGSN. The SGSN tracks the location of amobile station only at the Routing Area level, whereas a RNC knows thecell in which a mobile station is.

[0011] When a mobile station changes location, it may change cell.Usually the cell is selected based on the strength of the downlink radiotransmissions. If the source (original) cell and the target cell do notbelong to the same routing area, a PS-attached mobile station performs arouting area update. Consider as an example in FIG. 1 a situation, wherethe mobile station (which is in a PMM Idle state) changes the cell fromthe BS2 111 a to the BS3 111 c. FIG. 2 presents an example of a messagesequence chart of a inter-SGSN routing area update, where the targetSGSN is not the source SGSN, e.g. the target SGSN is SGSN2 and thesource SGSN is SGSN1 in FIG. 1. The routing area update procedure beginswith a Routing Area Update Request 201 sent by the MS to the targetSGSN, to which the target RNC is connected. The target SGSN sends a SGSNContext Request 202 to the source SGSN. This message indicates the PTMSIor IMSI of the MS, the target Routing Area identifier (RAI) and somesecurity information. Once the MS has been authenticated, the sourceSGSN which responds with a SGSN Context Response 203. This messagescarries, for example, information about the IMSI of the MS and about thePDP contexts of the MS. After the SGSN Context Response, the target SGSNmay trigger the RAN to perform some security functions with the MS.Thereafter, if the MS is authenticated properly, the target SGSN sends aSGSN Context Acknowledgement 204 to the source SGSN.

[0012] The target SGSN sends Update PDP Context Request 205 to theproper GGSN or GGSNs. This message indicates, for example, the addressof the target SGSN Address, a SGSN Tunnel Endpoint Identifier and a GGSNTunnel Endpoint Identifier. The GGSN Tunnel Endpoint Identifier is usedby the GGSN to identify the PDP context. The GGSNs update their PDPcontext fields and return an Update PDP Context Response 206 to thetarget SGSN. Thereafter the target SGSN informs the HLR of the change ofSGSN by sending Update Location message 207 indicating the target SGSNand the IMSI of the MS.

[0013] Cancel Location and Cancel Location Ack messages 208 and 209between the HLR and the source SGSN inform the source SGSN that it candelete information about the MS. Insert Subscriber Data message 210 issent by the HLR to the target SGSN and it carries subscriber informationrelated to the MS. The target SGSN confirms by sending Insert SubscriberData Ack message 211. Thereafter the HLR sends an Update Location Ackmessage 212 to the target SGSN. Thereafter the target SGSN sends aRouting Area Update Accept message 213 to the MS, and the MS respondswith a Routing Area Update Complete message 214. If the routing areaupdate is an intra-SGSN, then only messages 201, 213 and 214 are sent.

[0014] A mobile station may communicate with more than one cells at thesame time. If the cells are controlled by more than one RNCs, one of theRNCs is the Serving RNC (SRNC). The serving RNC is responsible, forexample, for the control of the radio resources and for the control ofthe uplink and downlink packets. The other RNCs are usually called driftRNCs and they typically just relay data packets between the MS and theServing RNC. In FIG. 1, for example, the mobile station may becommunicating with base stations BS2 111 b and BS3 111 c, and theserving RNC may be the RNC1 112 a. When the mobile station, for example,moves farther away from the base station BS2 111 b, the relocation ofthe Serving RNC becomes relevant because the MS may communicate onlywith the base station BS3 111 c. The route of packet data between theGGSN and the MS may be, for example, before the SRNC relocationGGSN—SGSN1—RNC1—RNC2—BS2—MS.

[0015] When the mobile station is in a PMM connected state, an SRNCrelocation procedure is always performed before RAU procedure. FIG. 3presents a message sequence chart of the steps of the relocation of aServing RNC before the routing area update. The source RNC sends a SRNCRelocation Required message 301 indicating the target RNC and carryingan information field to be passed to the target RNC to the source SGSN.If the SRNC relocation is an inter-SGSN SRNC relocation, the source SRNSsends a Forward SRNC Relocation message 302 to the target SGSN.Thereafter the target SGSN sends a SRNC Relocation Request message 303,which carries the information field originally sent in the SRNCRelocation Required message 301, to the target RNC. The target RNC andthe target SGSN establish necessary bearers to the user data betweenthemselves (i.e. over the Iu interface). Thereafter the target RNC sendsa SNRC Relocation Ack message 304 to the target SGSN. This messageindicates the RNC IP address(es) (possibly one address per PDP context)on which the target RNC is willing to receive packet data and Tunnel EndPoint Identifier(s) which are the identifiers to be used in GTP levelwhen sending packets to this RNC.

[0016] When the traffic resources between target RNC and target SGSN areallocated and the target SGSN is ready for the SRNC move, then theForward SRNC Relocation Response message 305 is sent from the targetSGSN to the source SGSN. This message indicates that the target SGSN andRCN are ready to receive from source RNC the downstream data packets notyet acknowledged by the MS.

[0017] When the Forward SRNC Relocation Response message 305 is receivedin the source SGSN, the source SGSN indicates the completion ofpreparation phase at the CN PS domain side for the SRNC relocation bysending the SRNC Relocation Command message 306 to the source RNC. Themessage comprises IP address(es), and Tunnel End Point Identifier(s)that can be used by source RNC to send the downstream packets not yetacknowledged by the MS to the target RNC.

[0018] When the source RNC has received the SRNC Relocation commandmessage 306, it sends a SRNC Relocation Commit message 307 to the targetRNC. This Commit message indicates the GTP sequence number for the nextdownlink packet (SND) to be received from the GGSN, the GTP sequencenumber for the next uplink packet (SNU) to be tunneled to the GGSN andUP_RLC_Ack contains the acknowledgements for upstream PDU received bythe source RNC on each RLC connection used by the UE. The source RNCstops the exchange of the packets with the MS, and starts tunneling thebuffered and incoming downstream packets towards the target RNC usingRNC IP address(es) and Tunnel End Point Identifier(s) indicated in theSRNC Relocation Command message 306.

[0019] At this point the target RNC, i.e. RNC2, starts acting as theServing RNC. The downlink and uplink packets are transmitted between thetarget RNC and the MS, and the target RNC, instead of the source RNC,controls the transmission. The target RNC sends New Mobility ManagementSystem Information message 307 to the MS indicating e.g. relevantRouting Area and Location Area. The target RN identifier, which isdifferent from the source RAI, triggers a RA Update procedure whichstarts by the mobile station sending Routing Area Update message 201.Before this procedure the downlink packets arrive, again referring tothe example presented in FIG. 1, the following route:GGSN—SGSN1—RANC1—RNC2—BS3—MS. After the RA Update, the GGSN can sendpackets intended for the MS directly to the SGSN2 and the route isGGSN—SGSN2—RNC2—BS3—MS.

[0020] The uplink traffic is not stopped due to the new MobilityManagement System Information or the RA Update procedure, because thetarget SGSN may send uplink packet to the GGSN before the update PDPcontext is performed. This is because the address of the SGSN sendinguplink packet to the GGSN is not checked.

[0021] Immediately after a successful switch at RNC, the target RNC,which is now the serving RNC, sends SRNC Relocation Detect message 308to the SGSN2. After sending out the New MM System Information message309, the target RNC sends an SRNC Relocation Complete message 310 to thetarget SGSN. The target SGSN sends an Update PDP Context Request message311 (new SGSN Address, QoS Negotiated, SGSN Tunnel Endpoint Identifier,GGSN Tunnel Endpoint Identifier) to the GGSNs concerned. GGSN TunnelEndpoint Identifier is used by GGSN to identify the PDP context TheGGSNs update their PDP context fields and return an Update PDP ContextResponse message 311 (GGSN Tunnel Endpoint Identifier). The target SGSNsends Complete Serving RNC relocation message 312 to the source SGSNwhen all GGSNs have been updated.

[0022] If the serving RNC relocation is an inter-SGSN SRNC relocation,there is no need for the RA update procedure which starts with themessage 201. Further, the Forward SRNC Relocation messages 302 and 305,Update PDP Context messages 311 and Complete SRNC Relocation message 312in FIG. 3 are not needed. As can be seen in FIGS. 2 and 3, therelocation of a serving SRNC including a routing area update involves alarge number of messages. If only the phase of SRNC relocation precedingthe RA update is studied, there are at least 12 messages involved in theinter-SGSN SRNC relocation. In an error situation, where the source RNC,for example, does not receive the SRNC Relocation Command, the problemcan be caused by the source SGSN, the target SGSN or the target RNC.Furthermore, the uplink and downlink packet transmission is usuallyinterrupted during SRNC relocation.

[0023] The object of the invention is to present a robust and simplemethod for relocating a serving network entity.

[0024] The object of the invention is achieved by letting the target andsource network entities to negotiate the relocation of a serving networkentity between themselves.

[0025] A method according to the invention is a method for relocating aserving network entity related to a certain terminal, where

[0026] before the relocation certain packet data information istransmitted between the terminal and a first network entity at least viaa second network entity, which is connected to the first network entitywith a first path, and via a third network entity, which is connected tothe first network entity with a second path and to the second networkentity, which is a peer entity of the third network entity, with a thirdpath, which first, second and third paths are separate paths,

[0027] before the relocation the second network entity is acting as theserving network entity,

[0028] after the relocation said information is transmitted via thethird network entity, which is acting as the serving network entity, and

[0029] a need for serving network entity relocation from the secondnetwork entity to the third network entity is detected, and the need forrelocation is communicated to the third network entity by the secondnetwork entity using the third path, and a routing area update procedureis triggering the relocating.

[0030] The invention relates also to a network entity, which is arrangedto perform a role of a serving network entity, the network entitycomprising

[0031] means for sending a message indicating need for a relocation of aserving network element to a peer network entity

[0032] means for receiving the message from a peer network entity, and

[0033] means for triggering the relocation in accordance with a routingarea update procedure.

[0034] In a method according to the invention, a relocation of a servingnetwork entity related to a certain packet data connection is performed.The packet data connection may be, for example, a connection between amobile station and a terminal on the other side of a public packetnetwork. There are at least three network entities involved in theinformation transmission. The first network entity may be, for example,a Serving GPRS Support Node of the UMTS core network. The two othernetwork entities (the second and third network entities) are peers, andone of them is performing as the serving network entity. Term servingnetwork entity refers to a situation, where there are two peer networkentities transmitting the data packets related to this certainconnection. The other network entity, which controls the transmission ofpacket and, for example, the use of transmission resources, is calledthe serving network entity. The other peer network entity, which issimilar to its peer, basically relays the user data and signaling data.The serving network entity and its peer may be, for example, radionetwork controllers of a radio access network.

[0035] In the method according to the invention, the need for therelocation of a serving network entity is communicated by the servingnetwork entity to its peer network entity using a path that does notinclude the first network entity. Because the second and third networkentities can act as serving network entities, they have the informationneeded, for example, to control the transmission of the packet data andthe transmission resources. They can also detect the need for therelocation of a serving network entity. There is thus no need forentities from other hierarchical levels (i.e. non-peer entities) to beinvolved in the beginning of the serving network entity relocation. Thepath connecting the peer network elements may comprise, for example,routers. This is typically the case when the peer network elements areconnected to each other using a packet data network. Term path refershere to a path, for example formed by cables and routers, connecting theendpoints and including the endpoints (network entities). Term separatepaths refers here to a situation, where none of the paths forms a partof other path. The paths may, however, have common parts. For example,two paths may involve certain same routers as long as at least one ofthe endpoints is different.

[0036] Once the role of the serving network entity is changed to thethird network entity, for example to a target radio network controller,there is no need to keep the second network entity involved in thepacket data transmission. Either of the peer network entities may informthe first network entity that the path of the packet data transmissionshould be changed. This is further discussed in conjunction with thepreferred embodiments of the invention.

[0037] One of the advantages of the invention is that the peer networkentities, for example in the radio access network, can prepare therelocation of a serving network entity. This way the other networkentities, for example entities in a core network, need not consumeresources for actions that are carried out between the peer entities. Afurther advantage is that the possible error situations are easier tohandle: if there are only to entities involved in certain steps of aprocedure, it is easier to determine the cause, for example, for amissing protocol message. Further, the response for a request to performa relocation of a serving network entity is received quickly.

[0038] The method according to the invention is especially suitable fornetwork entities that are connected to each other using a packetswitched network. In these networks it is not necessary to establish aconnection before sending signaling messages or user data. Inconjunction with the preferred embodiments, the situation wheresignaling is performed using point-to-point connections is discussed.

[0039] The appended dependent claims describe some preferred embodimentsof the invention.

[0040] The invention will now be described more in detail with referenceto the preferred embodiments by the way of example and to theaccompanying drawings where

[0041]FIG. 1 illustrates an example of a UMTS core network and radioaccess network,

[0042]FIG. 2 illustrates a message sequence chart of a routing areaupdate,

[0043]FIG. 3 illustrates a message sequence chart of a serving radionetwork controller relocation,

[0044]FIG. 4 illustrates a flowchart of a method for relocating aserving network entity according to a first preferred embodiment of theinvention,

[0045]FIG. 5 illustrates network elements according to the invention,

[0046]FIG. 6 illustrates a message sequence chart of a relocation of aserving radio network controller according to a second preferredembodiment of the invention,

[0047]FIG. 7 illustrates a message sequence chart of a routing areaupdate related to the relocation of a serving radio network controlleraccording to the second preferred embodiment of the invention,

[0048]FIG. 8 illustrates the transmission of user data during variousphases of the relocation of a serving radio network controller accordingto the second preferred embodiment of the invention, and

[0049]FIG. 9 is a schematic drawing illustrating the method according tothe invention.

[0050] Above in connection with the description of the prior artreference was made to FIGS. 1-3. The same reference numerals are usedfor corresponding parts in the figures.

[0051]FIG. 4 presents a flowchart of a method 400 for relocating aserving network entity according to a first preferred embodiment of theinvention. In the beginning of the method, the source network entityacts as the serving network entity (step 401). It detects the need forrelocation (step 402) and contacts the peer network entity, which is thetarget of the relocation (step 403). The target entity prepares to actas a serving network entity (step 404). Here it may need informationabout the packet data connection and this information can be transmittedin step 403.

[0052] Once the target network entity has completed the preparations, itsends a confirmation message to the source entity. If the target networkentity cannot act as a serving network entity, it may communicate therefusal to the source network entity. In this case, the target networkentity may try to find another peer network entity that can act as theserving network entity.

[0053] After receiving a confirmation message, the source network entitysends to the target network entity a message indicating that from thereceipt of the message the target network entity is responsible foracting as the serving network entity, and simultaneously, it stopsacting as the serving network entity (step 406). After the relocation,the target network entity is the serving network entity (step 407).

[0054]FIG. 5 shows two peer network entities 501, 502 according to theinvention. Each of these network entities is able to act as a servingnetwork entity. This is represented in FIG. 5 with the block 510. Thecapability to act as a serving network entity comprises the capabilityof detecting the need for relocation of the serving entity andconstructing a message (including necessary information about the packetdata connection and quality of service requirements, for example)indicating this need. The network entities 501, 502 according to theinvention comprise a block 511 which is responsible for sending themessage to a peer network element. They also comprise a block 512 whichis used to receive the message indicating the need for relocation from apeer network element.

[0055] In FIG. 5 the network entity 501 comprises also a block 513 usingwhich a non-peer network entity is notified of the change of peernetwork entity address. This notification may comprise, for example, anew network address where the non-peer network entity should after thereceipt of the message send data packets related to a certain packetdata connections, a new Tunnel End Point Identifier which the non-peernetwork entity should after the receipt of the message add to every datapackets related to a certain packet data connections. The usage of themodify tunnel message to change the destination address from a peernetwork entity to another is new (previously, this message was onlyplanned to change the connection from one computer unit to anotherwithin the same entity). In one alternative embodiment, the peer networkentity also provides to the non-peer network entity a notificationcomprising a new network address where the non-peer network entityshould after the receipt of the message send signaling message relatedto a certain packet data connection or to a certain Mobile Station.

[0056] The blocks 511 and 512 are most probably part of a certainprotocol. If the network entities 501, 502 according to the inventionare, for example, radio network controllers of a radio access network ofthe UMTS cellular system, the protocol may be the RNSAP (Radio NetworkSubsystem Application Part), and, the block 513 may be part of the RANAP(Radio Access Network Application Part) protocol. And the procedure usedto modify the tunnel between a RNC and a SGSN may be the RAB (RadioAccess Bearer) Assignment procedure.

[0057]FIG. 6 shows a message sequence chart of a method for relocating aserving RNC related to a certain mobile station according to a secondpreferred embodiment of the invention. In the beginning of this method,there is a serving RNC and a drift RNC involved in the packet datatransfer related to a certain mobile station. The route of data packetbetween the mobile station and, say, and GGSN is (using the examplepresented in FIG. 1) MS—BS2—RNC2—RNC1—SGSN1—GGSN. This is also presentedin FIG. 8a, where the arrows 801, 802, 803, 804 refer to bidirectionalinformation transmissions between the network elements. The source RNCand the mobile-station are the endpoints of the packet data transmission802, 801 in the radio access network.

[0058] In this method the source RNC detects the need to perform aServing RNC relocation and determines the target RNC. It knows, forexample, the network address where to send signaling messages intendedfor this target RNC and it sends a SRNC Relocation Prepare message 601to the target RNC. The message indicates, for example, the IMSI of themobile station, a network address for sending uplink packets (forexample, the address of the source SGSN), SGSN Tunnel EndpointIdentifier (TEID), and Quality of Service profile of the MS. In a firstalternative embodiment, the network address to be used for uplinksignaling is also sent in this message.

[0059] After receiving the SRNC Relocation Prepare message 601, thetarget RNC prepares itself to receive downlink packets intended for themobile station and, consequently, establishes a context for this mobilestation and selects RNC TEID and the RNC network address for thesedownlink packets. The IMSI of the mobile station and the Quality ofService profile are needed in this preparation. Thereafter the targetRNC sends a SRNC Relocation Prepare Acknowledgement message 602 to thesource RNC. This message indicates, for example, the network address,where the source RNC can forward downlink data packets intended for themobile station and possibly the RNC TEID established for these packets.In a second alternative embodiment, the network address to be used fordownlink signaling is also sent in this message. But the source RNC isstill acting as the Serving RNC and the data transmission is notmodified until a SRNC Relocation Commit message is sent. The source RNCsends the SRNC Relocation Commit message 307 which includes allnecessary radio parameters and PDCP (Packet Data Convergence Protocol)parameters needed by the target RNC to start the control of the radioconnections, in other words, the target RNC becomes the serving RNC. Atthis point the source RNC stops downlink transmission to the mobilestation through the path 802 and forwards the downlink packets intendedfor the mobile stations to the target RNC using the path 822, aspresented in FIG. 8b. The protocol used for the transmission presentedby arrow 822 may be GTP-U (GPRS Tunneling Protocol for the User plane),and it is different from the protocol for the transmission presented byarrow 802. The downlink packets using the path 822 are sent to thenetwork address comprised in the SRNC Prepare Acknowledgement message602 and the packets include the RNC TEID comprised in that message.

[0060] If the SRNC Relocation Prepare message 601 also comprises anetwork address where to forward uplink packets and a SGSN TEID for thepackets, the target RNC may after receiving the SRNC Relocation Commitmessage 307, forward the uplink packets sent by the mobile stationdirectly to the source SGSN (see arrow 823 in FIG. 8b). The SGSNtypically does not check the address of the sender of packets, so itdoes necessarily not even notice that the sender of the packets is thetarget RNC instead of the source RNC.

[0061] To change the route for the downlink packets, the source RNCsends a Modify Tunnel message 603 to the source SGSN. This message is anoptional message and it can, for example, also inform the source SGSNthat a serving RNC relocation has taken place. The message indicates,for example, the network address of the target RNC and possibly the RNCTEID related to the downlink packets. This information is typicallyprovided to the source RNC in the SRNC Relocation PrepareAcknowledgement message 602. An alternative is that the target RNC,which is currently the serving RNC, informs the source SGSN of the SRNCrelocation and/or change of paths for example by sending a Modify Tunnelmessage. The necessary information can be provided to the target RNC bythe source RNC, for example, in the SRNC Prepare message 601. In analternative embodiment, the target RNC may also inform of the newdownlink address for signaling information, and establish the newsignaling connection. This information may be sent using a new messageto modify signaling link. After the source SGSN modifies the tunnelbetween itself and an RNC, i.e. includes in its context the new RNC TEIDand the new RNC network address, the route of the data packets is suchas presented in FIG. 8c with arrows 801, 833 and 804. The datatransmission 804 between the SGSN and the GGSN is not affected by themere relocation of the serving RNC.

[0062] The target RNC, after taking the role of the serving RNC, sendsto the mobile station a RRC Status message 604. This message carries aRouting Area Identifier corresponding to the target routing area. Themobile station verifies the receipt of the RRC Status message with RRCStatus Ack message 605. Alternatively, the MM system informationmessages can be exchanged between the mobile station and the target RNC,similarly as Presented in FIG. 3. If the source RNC and the target RNCbelong to the same routing area, the rest of the relocation SRNCprocedure is related to the signaling link: the signaling link betweenthe source RNC and the source SGSN is torn down and a signaling linkbetween the target RNC and the source SGSN is established. Signaling canbe supported either by a packet switched network (for example, an IPnetwork) or with point-to-point connections (such as the BroadbandSignalling System 7). In each case the updating of signaling links isstraightforward. In the said second alternative embodiment, where theSRNC Relocation Prepare Ack message 602 comprises an address for thedownlink signaling, the signaling link can be modified by the sourceRNC, by indicating the new network address where SGSN should after themodification procedure send signaling messages related to a certainpacket data connection or to a certain Mobile Station. In the said firstalternative embodiment, where the SRNC Relocation Prepare message 601comprises an address for the uplink signaling, the signaling link can bemodified by the target RNC, by indicating the new network address whereSGSN should after the modification procedure send signaling messagesrelated to a certain packet data connection or to a certain mobilestation.

[0063] If the mobile station notices that the RAI in the RRC Statusmessage is different from the present RAI, it starts the Routing AreaUpdate procedure with the Routing Area Update Request message 201. Whenthe signaling is done using point-to-point connections and the ServingRNC relocation procedure is an inter-SGSN SRNC relocation procedure, thesource SGSN cannot exchange signaling messages with the target RNC. Inthis case, the source RNC may, for example, set the state of the Iusignaling connection of this mobile station to a signaling-suspended dueto SRNC relocation state. If the source SGSN sends signaling messages tothe source RNC, it may return an error message indicating the suspendedstate. The source SGSN may then also enter a signaling-suspended statefor the In signaling connection of this mobile station. In this case,the mobile station originating signaling messages are sent from thetarget RNC to the target SGSN. Messages not related to RAU may beignored until the RAU procedure is complete.

[0064] If the signaling connections are supported by a packet switchednetwork, it is also possible to have a signaling link between the targetRNC and the source SGSN. The user data packets are transmitted betweenthem, and they may also exchange signaling messages also in theinter-SGSN Serving RNC relocation procedure.

[0065]FIG. 7 presents the message sequence chart of the Routing AreaUpdate procedure that forms the second part of the method for relocatinga serving RNC according to the second preferred embodiment of theinvention. It starts with the Routing Area Update Request message 201that the mobile station sends to the target SGSN. Thereafter the targetand source SGSNs exchange SGSN Context messages 202, 203 and 204 asexplained in context of prior art.

[0066] The SGSN Context Response message 203 carries information aboutthe PDP context of the mobile station. The target SGSN notices based onthis information that a packet data tunnel was active on between thetarget RNC and the source SGSN. The target SGSN aims to transfer theother endpoint of this tunnel from the source SGSN to itself. Thereforeit sends a RAB Establishment Request message 701, which indicates theSGSN TEID, the new address for sending uplink data packets and Qualityof Service parameters, to the target RNC. The target RNC notices that italready has a RNC TEID in use for this data transmission of this user,and updates the uplink network address and the SGSN TEID. Thereafter itsends a RAB Establishment Response message 702 to the target SGSN. Thismessage indicates the proper address for downlink data packets, RNC TEIDand Quality of Service parameters. The target RINC may immediately startto send uplink data packets to the target SGSN, which in turn forwardsthem to the GGSN (see arrow 844 in FIG. 8d). The GGSN typically does notcheck the sender of packets, and thus is does not mind the uplink packetbeing sent by the target SGSN instead of the source SGSN.

[0067] Thereafter the RAU procedure in FIG. 7 continues as the RAUprocedure described in connection with the prior art. After the GGSN hasupdated the PDP context related to this packet data connection, it cansend downlink data packets directly to the target SGSN (arrow 854 inFIG. 8e).

[0068] The SRNC Relocation Commit message 307, the Modify Tunnel message603 and the RAB Establishment Request/Response 701, 702 are existingmessages in the RANAP (Radio Access Network Application Part) protocol.The Modify Tunnel message is currently seen to be used by an RNC to, forexample, change computer unit handling a certain packet data connection.A RAB Assignment procedure is used to modify or release an alreadyestablished RAB or to establish a new RAB. For clarity, when thisprocedure is used to establish a new RAB, we named it in thisdescription a RAB establishment message/procedure, and when thisprocedure is used to modify a RAB, the message is called a Modify Tunnelmessage. On the Iu interface between a SGSN and a RNC, a certain GTPtunnel corresponds to a RAB in the radio access network, and this GTPtunnel can be modified with the Modify Tunnel message (whose exactstandard name is RAB Assignment Request message).The RRC Status and RRCStatus Ack are also existing messages of the RRC protocol.

[0069]FIG. 9 presents a drawing that illustrates further the methodaccording to the invention. Before the relocation of the serving networkentity packet data information is transmitted between a terminal and afirst network entity (901) at least via a second network entity (902)and via a third network entity (903). The first network entity (901) isconnected to the second network entity (902) with a first path (911) andto a third network entity (903) with a second path (902). The thirdnetwork entity is a peer network entity of the second network entity,and it is connected to the second network entity with a third path(903). The first, second and third paths are separate paths.

[0070] The second network entity acts before the relocation as theserving network entity. In a method according to the invention, the needfor relocation of the serving network entity is communicated (601) tothe third network entity by the peer second network entity using thethird path. The relocation prepare message, for example, is nottransmitted via the first network element. After the relocation saidpacket data information between the terminal and the first networkelement is transmitted via the third network entity.

[0071] The RNC and SGSN of the UMTS system are used here as examples ofa network and examples of network entities where the invention can beapplied. The method and network entities according to the invention canalso be applied in other networks, especially in other cellularnetworks, and between other network elements.

[0072] In view of the foregoing description it will be evident to aperson skilled in the art that various modifications may be made withinthe scope of the invention. While preferred embodiments of the inventionhave been described in detail, it should be apparent that manymodifications and variations thereto are possible, all of which fallwithin the scope of the invention.

1. A method (400) for relocating a serving network entity related to acertain terminal, where before the relocation certain packet datainformation is transmitted (801, 802, 803) between the terminal and afirst network entity (901) at least via a second network entity (902),which is connected to the first network entity with a first path, andvia a third network entity (903), which is connected to the firstnetwork entity with a second path and to the second network entity,which is a peer entity of the third network entity, with a third path,which first, second and third paths are separate paths, before therelocation the second network entity is acting as the serving networkentity, after the relocation said information is transmitted (801) viathe third network entity, which is acting as the serving network entity,and a need for serving network entity relocation from the second networkentity to the third network entity is detected (402), characterized inthat the need for relocation is communicated (403, 601) to the thirdnetwork entity by the second network entity using the third path, and arouting area update procedure is triggering the relocating.
 2. A methodaccording to claim 1, characterized in that a first message (601)indicating the need for relocation of a serving network entity is sent(403, 601) by the second network entity to the third network entityusing the third path and a second message (602) indicating thecapability to act as a serving network entity is sent (405, 602) by thethird network entity to the second network entity.
 3. A method accordingto claim 2, characterized in that information enabling transmission(823) of uplink information from the terminal to the first networkelement using the second path is transmitted in the first message (601).4. A method according to claim 3, characterized in that informationenabling the transmission of user data is transmitted in the firstmessage (601).
 5. A method according to claim 3, characterized in thatinformation enabling the transmission of signaling data is transmittedin the first message (601).
 6. A method according to claim 2,characterized in that a third message indicating the relocation of aserving network entity is sent (307) to the third network entity by thesecond network entity using the third path and onwards from a certainfirst time, which is after receipt of the third message, the tasks ofthe serving entity are carried out (407) by the third network entity. 7.A method according to claim 6, characterized in that at a certain secondtime after the first time, certain information is communicated (603) tothe first network entity.
 8. A method according to claim 7,characterized in that at the second time the change of path from saidfirst path to said second path for downlink information from the firstnetwork entity to the terminal is communicated (603) to the firstnetwork entity by the second network entity.
 9. A method according toclaim 7, characterized in that at the second time the change of the pathfrom said first path to said second path for downlink information fromthe terminal to the first network entity is communicated (603) to thefirst network entity by the third network entity.
 10. A method accordingto claim 7, characterized in that the path of signaling information ischanged from the first path to the second path and the change isinitiated by the second network entity or the third network entity. 11.A method according to claim 7, characterized in that onwards from acertain third time after the second time and at least during a certaintime interval, said information is transmitted (833) between the thirdnetwork entity and the first network entity using the second path.
 12. Amethod according to claim 11, characterized in that downlink informationis that said information which is transmitted to the terminal and uplinkinformation is that said information which is transmitted by theterminal and during a certain time interval between the first time andthe third time, said downlink information is transmitted (822) from thefirst network entity to the third network entity using the first pathand the third path and said uplink information is transmitted (823) fromthe third network entity to the first network entity using the secondpath.
 13. A method according to claim 11, characterized in that at acertain fourth time after the second time, the routing area which ishandled by the third network entity and to which the terminal belongs iscommunicated (604) to the terminal.
 14. A method according to claim 13,characterized in that the first routing area, which is handled by thethird network entity, is different from the second routing area, whichis handled by the second network entity, and a fourth message is sent(201) by the terminal to a fourth network entity, which is a peernetwork entity of the first network entity, belongs to the first routingarea, and is connected to the first network entity with a fourth pathand to the third network entity with a fifth path, which said fourthpath and fifth path are separate from the first path, the second pathand the third path.
 15. A method according to claim 14, characterized inthat a fifth message indicating that said information is to betransmitted to the fourth network entity instead of the first networkentity is sent (701) to the third network entity and onwards from acertain fifth time, which is after the receipt of the fifth message,said information is transmitted (853) between the third network entityand the fourth network entity using the fifth path.
 16. A methodaccording to claim 15, characterized in that before the receipt of afifth message, said information is transmitted (804) further between thefirst network entity and a fifth network entity, which is connected tothe first network entity with a sixth path and to the fourth networkentity using a seventh path, a sixth message indicating said informationis to be transmitted between the fourth network entity and fifth networkentity using the seventh path is sent (206) to the fifth network entityand during a certain time interval after the receipt of the fifthmessage, said uplink information is transmitted (844) from the thirdnetwork entity to the fifth network entity using the second path and thesixth path and said downlink information is transmitted (843) from saidfifth network entity to the third network entity using the seventh pathand the fifth path.
 17. A method according to claim 1, characterized inthat the terminal is a mobile station, the second network entity andthird network entity are entities of a radio access network of acellular system and the first network entity is a network entity of acore packet network of the cellular system.
 18. A method according toclaim 17, characterized in that the second and third network entitiesare radio network controllers of the UMTS cellular system and the firstnetwork entity is a Serving GPRS Supporting Node of the UMTS cellularsystem.
 19. A network entity (501, 502), which is arranged to perform arole of a serving network entity (510), characterized in that thenetwork entity comprises means (511) for sending a message indicatingneed for a relocation of a serving network element to a peer networkentity means (512) for receiving the message from a peer network entity,and means for triggering the relocation in accordance with a routingarea update procedure.
 20. A network entity according to claim 19,characterized in that it further has means (513) for informing a networkelement that a relocation of a serving network entity that has takenplace.
 21. A network entity according to claim 19, characterized in thatit is a network entity of the radio access network of a cellular system.22. A network entity according to claim 21, characterized in that it isa radio network controller of the UMTS radio access network.